ICOD (Instant Capacity On Demand) systems are computer systems that typically include one or more inactive components (known as ICOD components) when shipped to the user. As the term is employed herein, an inactive or ICOD component is a software or hardware component that the user has not paid for and is not entitled to use as a matter of right.
Vendors include inactive or ICOD components in a computer system for many reasons. For example, a vendor may anticipate that a particular user may need additional software and/or hardware capability in the future and may wish to include the additional capability in an inactive form so that the additional capability can be quickly enabled at a later date if needed. The ICOD components may be processors, memory, cells, subsystems, or the like, and can be activated when the user wishes to obtain additional capability from the ICOD system.
Generally speaking, when an ICOD system is shipped to a user, either the vendor or the customer will deactivate the inactive components so that only the components that have been paid for will be active during use. This deactivation may happen one time prior to shipping, or the ICOD system may include software to automatically deactivate the inactive components upon system booting based on the licensing data stored in the ICOD system itself.
To ensure compliance, vendors in the past employ an ICOD software agent, e.g., codes in the ICOD system, to periodically take inventory of the inactive (or active) components and compare the number of inactive (or active) components with the licensing data stored in non-volatile memory. The data regarding the number of inactive (or active) components, along with other identification information such as the serial number of the computer system, the host name, the IP address, and the like may then be sent in an email to the vendor to allow the vendor to audit for compliance.
If a user's computer system uses more active components therein than the number of active components allowed under license, the user's system is deemed to be in a non-compliant state, and the vendor may undertake any number of corrective actions. For example, the vendor may wish to send a sales representative to the user whose system is found to be in a non-compliant state in order to suggest the licensing of the activated components. As another example, the vendor may notify the user of the non-compliant status and request that the user either immediately pay for the use of the inactive components, or to cease the non-compliant use.
An exception to the above exists when the user has purchased temporary capacity with the vendor. In general, if the user maintains an adequate temporary capacity account with the vendor, the user can activate ICOD components temporarily and have the temporary capacity balance deducted for the ICOD component usage. Thus, as long as the user has an adequate temporary capacity available, the user can temporarily activate a greater number of components than that allowable under license. With the temporary capacity feature, users benefit from having the flexibility of being able to temporarily activate components to handle any unexpected and/or temporary need for additional capacity without having to commit in advance to a long term purchase. Vendors also benefit since the sale of temporary capacity represents an additional revenue stream for the vendors.
Traditionally, the customer's temporary capacity account is tracked by the vendor. On a periodic basis, the ICOD software agent sends data regarding the number of components active in the user's computer system to vendor. The data may be transmitted in an email via the Internet, for example. The vendor's auditing system then calculates the number of components activated in excess of that allowable under license as well as the amount of temporary capacity consumed in order to adjust the user's temporary capacity balance.
To facilitate discussion, FIG. 1 illustrates a simplified exemplary ICOD system 100 having four CPUs 102, 104, 106, and 108. In the example of FIG. 1, CPUs 102 and 104 represent licensed CPUs, i.e., CPUs that the user has already paid for and is entitled to use as a matter of right. CPUs 106 and 108 represent ICOD CPUs, which are normally deactivated in ICOD system 100.
An ICOD software agent 110 is provided to enable user 112 to activate and deactivate the CPUs, via a terminal 114, to meet the user's capacity demand. On a periodic basis, e.g., every 24 hours, ICOD software agent 110 takes an inventory of the number of CPUs active in ICOD system 100 and sends an email to the vendor's audit system 116 via a network 117 to facilitate auditing. Audit system 116 includes an audit database 118, which stores the licensing information for the various ICOD systems sold by the vendor. For example, audit database 118 may track the serial number of a particular ICOD system, such as ICOD system 100, along with the number of ICOD CPUs therein (e.g., the two CPUs 106 and 108 in the present example). Audit database 118 also tracks a temporary capacity balance (shown by reference number 120) for ICOD system 100.
If ICOD system 100 is found to have a greater number of CPUs activated than that allowed under license, audit system 116 debits the temporary capacity balance for ICOD system 100. For example, if 3 CPUs are active per the audit email from ICOD software agent 110, ICOD system 100 is deemed to have 1 ICOD CPU activated (3 minus the two allowed under license). Since the audit email is received once every 24 hours, 24 CPU-hours (1 CPU times 24 hours) may be deducted from the temporary capacity balance for ICOD system 100.
If the temporary capacity balance drops below a certain threshold, auditing system 116 may, for example, send an email to the user to inform the user of the low temporary capacity balance and/or to request that the user replenish the temporary capacity account. This is represented by arrow 122 in FIG. 1. The user may replenish the temporary capacity account by making a purchase of additional temporary capacity units from the vendor, for example.
There are, however, disadvantages associated with the arrangement of FIG. 1. For example, the fact that the temporary capacity account is kept only at the vendor renders it difficult for ICOD software agent 110 to take enforcement action based on an insufficient temporary capacity balance. In ICOD system 100 of FIG. 1, ICOD software agent 110 has no knowledge of the temporary capacity and therefore cannot initiate enforcement action based on an insufficient temporary capacity.
Although audit system 116 can send emails to request the user to purchase additional temporary capacity units to address a negative temporary capacity balance, for example, some users may simply ignore such a request while continuing to utilize the non-compliant ICOD components. In this case, the vendor may eventually need to resort to sending field service personnel to the user's site to disable and/or remove the ICOD components. Additionally or alternatively, the vendor may need to resort to legal action to collect payment for the ICOD component usage and/or to repossess the computer system.
Furthermore, since the temporary capacity account is kept only with auditing system 116, the only way the user could find out about his temporary capacity availability is by contacting the vendor and asking for the temporary capacity balance data. If there is a delay in collecting and processing the temporary capacity account data at the vendor's auditing system and/or in processing the user's request, it may be some time before the user receives data regarding his own temporary capacity balance. During the delay, additional temporary capacity may have been consumed, rendering the received temporary capacity data untrustworthy. Without the ability to receive the temporary capacity balance information in an accurate and timely manner, it may be difficult for the user to forecast and plan for future capacity usage.
Furthermore, the auditing and enforcement mechanisms in FIG. 1 depend on the existence of email connectivity between ICOD system 100 and auditing system 116. It has been found, however, that many users are reluctant to endow their production ICOD systems with an email infrastructure, and to risk exposing their ICOD computer systems to the security risks that accompany email access. For some users, even the exposure of the host name to the outside world is unacceptable. For these users, the vendor has no visibility as to the number of ICOD components activated, and thus no reasonable way of tracking of the temporary capacity balance.